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TECHNICAL PAPER 


AUTOMATING A SPACECRAFT ELECTRICAL POWER SYSTEM 
USING EXPERT SYSTEMS 

I. INTRODUCTION 


The typical long-duration low-Earth orbit (LEO) spacecraft electrical power system (EPS) con- 
sists of an energy source, an energy storage element, a power management and distribution (PMAD) 
system, and loads. In the past, the majority of NASA's spacecraft have used solar energy sources, their 
energy storage elements have been batteries (usually nickel-cadmium (Ni-Cd)), their PMAD systems 
have been low-voltage dc ( + 28 Vdc) or 1 10 Vrms, 400 Hz ac, and the loads have totaled less than 10 
kW. These spacecraft were typically payload-driven designs, and even small variations in payload would 
greatly affect the efficiency and maintainability of the EPS [1], 

Future needs such as for Space Station Freedom (S.S. Freedom) and Moon/Mars missions will be 
on the order of tens of kilowatts to a few megawatts [2,3]. These new systems will contain increasingly 
more powerful and more complex elements. Energy sources could be concentrator solar arrays, solar 
dynamic, nuclear, or a combination. Energy storage, if separate from the source, could be advanced 
nickel-cadmium, nickel-hydrogen, lithium, or sodium-sulphur batteries, or advanced-momentum energy 
storage systems. The PMAD will require higher power and more efficient components as well as new 
EPS control technologies [2,4,5]. As a result of these new technologies and the increasing size, automat- 
ing the EPS has become an enabling technology for future large spacecraft. 


II. AUTOMATING THE ELECTRICAL POWER SYSTEM 


After the final crew left on February 9, 1974, and Skylab, NASA's first space station, was 
powered down, the EPS was evaluated. In the conclusion of this evaluation, 10 recommendations for 
future spacecraft electrical power systems were presented. Seven of these recommendations can be 
resolved by automating the EPS [6] . Based on these seven recommendations and experience from other 
spacecraft electrical power systems, NASA and its industrial and university partners began to investigate 
automating a spacecraft's EPS. 

The EPS is a natural candidate for automation. The EPS is of such complexity that any simplifica- 
tion can produce large benefits in cost and operation manpower reduction, yet it is of such simplicity that 
basic engineering concepts and experience can be translated into the hardware and software relatively 
easily. Many reasons exist for automating the EPS, two of the more significant are discussed in the 
following. 


A. Critical for Some Future Missions 


As NASA looks toward the 21st century, it has identified four mission goals to pursue: 
(1) enhanced capabilities for the S.S. Freedom ; (2) a manned lunar colony; (3) the manned 
exploration of Mars and Phobos; and (4) a detailed study of the Earth from space. In order to meet the 
increased load demands, each of these four missions will require larger and more complex power sys- 
tems. Because of this complexity, EPS automation will be required in order to control the system in real- 
time and to allow the crew to perform scientific experiments rather than devoting a lot of time to EPS 
operations. 

In addition to these manned missions, NASA is designing new unmanned interplanetary satel- 
lites, similar to the Pioneer series. Because of the distances involved, these satellites will require large 
complex power systems with the ability to operate without man or ground support for minutes to hours. 
Thus, EPS automation will be required to meet these needs. 


B. Reduced Operating Costs 

One of the most valuable commodities on any space mission is crew time. On the order of 
$20,000 per manhour, having an astronaut observe a voltmeter or switch status is terribly inefficient and 
very expensive. Therefore, the ability of automation to reduce crew interaction with the EPS will allow 
the crew more time to monitor science and materials processing experiments which require his attention. 
Besides the crew, ground support personnel are an integral part of any space mission. They perform 
many functions including preflight checkout, postflight data reduction, and on-orbit operations. Automa- 
tion techniques can aid in preflight checkout of the EPS by allowing a more friendly test computer user- 
interface, by being more flexible in failure mode testing, and by providing more detailed fault analyses. 
Postflight data analysis can be aided by data reducing programs. 

Other cost reduction benefits from automation will be gained by a reduction of ground-based 
personnel during orbital operations. As noted earlier, Skylab was the first example of a near-utility type 
power system. Skylab's EPS required a two-person team working around the clock to monitor, plot, and 
analyze the power system and to make recommendations to the operations manager relative to EPS 
operation [8]. If this level of effort, without automation, were scaled to the size of S.S. Freedom , the 
EPS operation would become prohibitively expensive. 

A further cost reduction can be realized through spacecraft weight savings. Using automation 
techniques, a spacecraft EPS can be designed to allow maximum use of the limited available power and 
energy. Solid-state circuit breakers and switchgear can be designed closer to their allowable operating 
ranges, thus providing smaller and lighter devices. Software techniques can be used to provide fault 
isolation and recovery, thus allowing for reductions in redundant hardware. 


III. THE NEED FOR EXPERT SYSTEMS 


If one accepts the need for power system automation, the next step is to establish the method(s). 
The early work (late 70’s to early 80’s) in automation concentrated primarily on the hardware with some 
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initial work on the level of and the complexity of the software that would be needed. These efforts pro- 
duced many useful and necessary results, but newer technologies would be required to fully automate the 
EPS. Thus, as a part of the 1984—1985 effort to investigate automating the S.S. Freedom EPS, the role of 
expert/knowledge-based systems technologies in this area was evaluated. 

As a result of this investigation, numerous functions in the EPS were determined to meet the 
necessary criteria to use expert/knowledge-based systems in their implementation. Some of these func- 
tions were power generation monitoring; energy storage management; fault detection, isolation, and 
recovery (FDIR); resource scheduling; and load management [7]. Each of these functional areas required 
decisions to be made with incomplete knowledge and/or a measure of uncertainty which meshed with the 
advantages of expert system technologies. In addition, this technology allows for flexible EPS develop- 
ment in order to establish the necessary algorithms needed for control. The remainder of this paper dis- 
cusses some of the numerous expert/knowledge-based systems applied to the EPS domain. 


IV. THE AUTONOMOUSLY MANAGED POWER SYSTEM 


The first steps taken toward automating an EPS began in 1978 with the start of the autonomously 
managed power system (AMPS) program. The AMPS program was funded by NASA’s Office of 
Aeronautics and Space Technology (OAST) through MSFC. The AMPS program was a three-phase 
program. The first phase was contracted to TRW and identified a reference photovoltaic EPS for a 
250-kW class LEO satellite. The second phase developed the autonomous power management approach 
for the reference EPS using efforts at TRW and in-house MSFC. The third phase developed a breadboard 
test facility at MSFC to evaluate, characterize, and verify the concepts and hardware resulting from 
phases 1 and 2 and utilizing hardware developed under other OAST space power program initiatives. 

At present, the AMPS test facility (fig. I) features two power channels feeding three power 
busses which in turn provide power to a load simulator. The two solar array simulators are rated at 75 kW 
and 17 kW capacity, respectively, while the 168-cell high-voltage Ni-Cd batteries are rated at 
180 Ampere-hours (Ah) and 55 Ah. The smaller battery is a flight-type battery retrieved from the Skylab 
project test bed. The load simulator consists of nine resistive loads and one dynamic load that consume a 
total of 24 kW of power when operated at 200 Vdc. Finally, four Motorola 68000 microcomputer-based 
controllers provide data retrieval and low-level decision making for the power system with a Sun 
4/330-based host computer providing programmability and status display for flight power system 
simulations [9]. 


V. THE SPACE STATION MODULE/POWER MANAGEMENT 
AND DISTRIBUTION TEST BED 


Based on the results of AMPS, a project to investigate automation techniques appropriate to a 
large PMAD system such as will exist on S.S. Freedom modules was begun in 1984 at MSFC. With the 
support of Martin Marietta Space Systems Group, a 25-kW space station module/power management and 
distribution (SSM/PMAD) test bed was developed [10], 
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Figure 1. The autonomously managed power system (AMPS). 




As figure 2 shows, this test bed hardware has two power distribution control units (PDCU's) and 
three load centers. The basic system design allows tor two additional load centers. Further, the test bed 
includes remote bus isolators (RBI's), remote controlled circuit breakers (RCCB's), and remote power 
controllers (RPC’s). Lastly, a lowest level processor (LLP) is included in each PDCU and load center. In 
the software area of the test bed, autonomy is pushed down to the lowest levels, specif ical ty , to the LLP s 
and through the switch interface processors to the "smart'' switchgear. Three artificial intelligence (AT) 
systems — the fault recovery and management expert system (FRAMES), the load priority list 
management system (LPLMS), and the master of automated expert scheduling through resource orches- 
tration (MAESTRO) — reside above and communicate with the other processors through the communica- 
tions and user interface (CUI) software [1 1|. The software will be described in more detail later. 


VI. EXPERT SYSTEMS IN THE AUTOMATION TEST BEDS 


A. AMPS Based 

Two expert system projects have been based on the AMPS test bed. One is the power system fault 
detection and recovery expert system named STARR. Two is a real-time fault detection and advisory 
expert system named the autonomously managed power system expertise reinforcing expert system 
(AMPERES). 

STARR is an object-oriented expert system featuring a parent object *SYSTEM for each of the 
five main objects (SA, SWITCH, BATTERY, D1ST, LOADS) which correspond to the actual AMPS 
test bed subsystems. STARR was created using Intellicorp’s Knowledge Engineering Environment 
(KEE) on a Xerox 1 109 (Dandelion) AI work station. Figure 3 is a display of all the objects in the know- 
ledge base and their inheritance hierarchy. STARR was interfaced to AMPS via the AMPS Ethernet local 
area network [12], 

STARR proved to be a valuable first attempt at EPS fault detection and recovery using expert 
systems. However, the lack of speed of the Xerox 1109 and the KEE environment precluded fully 
implementing STARR in the AMPS test bed. These deficiencies led to the AMPERES project. 

AMPERES is a real-time knowledge-based system which monitors the operational status of an 
EPS and provides fault diagnostic information. AMPERES uses the AMPS test bed at MSFC and is being 
developed by the University of Tennessee Space Institute (UTS1) [13]. 

AMPERES is composed of five major functional models to efficiently perform the necessary 
tasks (fig. 4). The fault monitoring and diagnosis task is decomposed into several subtasks, and each 
subtask is performed by a specialized module. The main controller module is a task-oriented inference 
engine which is organized and tuned to perform the given fault monitoring and diagnosis tasks. The 
status monitor module is responsible for assessing the current power system operational status. The fault 
diagnoser module is responsible for fault diagnosis and operator recommendations. The interface handler 
module is responsible for processing the various methods of input/output. The knowledge base (KB) 
module contains the necessary system information used to diagnose and monitor laults. Each module and 
submodule, except the natural language interface, the load of load schedule KB, and the statistic KB, has 
been initiated [13]. 
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Figure 2. Space station module/power management and distribution system (SSM/PMAD). 
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Figure 4. Autonomously managed power system extendible real-time expert system (AMPERES). 






The knowledge base is structured using a component-centered approach. Each component in the 
AMPS test bed is represented as an object in AMPERES using the structure definition in common LISP. 
An ammeter representation is shown in figure 5. The information included in each component representa- 
tion can be categorized into three groups: ( I ) the information about the component itself, (2) the func- 
tional environment of the component, and (3) the physical environment of the component. Fault monitor- 
ing and diagnosis knowledge is implemented in production rule forms (fig. 7) with the rule language 
being as close to natural language as possible which allows for ease of rule editing. 

In order to perform prototype testing with AMPERES at UTSI, a single power channel AMPS 
load simulator was developed. The simulator consists of an IBM PC compatible computer with an 
Ethernet interface and an AMPS-type power channel with a fault injector. This simulator is then inter- 
faced with a Sun 386i which houses AMPERES. Preliminary results with the simulator have been good, 
with the final goal of interfacing AMPERES with AMPS to be completed in early 1991. 


B. SSM/PMAD Based System Software 

The system software is distributed through several different types of processors and at different 
hierarchical levels. The LLP's are located at the level nearest the power hardware. The CUI software is 
notified of any anomalies by the LLP. FRAMES, MAESTRO, and LPLMS share the highest level of the 
hierarchy. Each step up this hierarchy reveals a decrease in speed (microseconds at the switchgear level, 
milliseconds to seconds at the LLP level, seconds to minutes at the AI level (fig. 6)) and an increase in 
sophistication [10], 

The LLP's consist of Intel 80386-based computers and an Ethernet communication board. An 
LLP is located in each load center, subsystem distributor, and PDCU. Each LLP is responsible for con- 
trolling the switches associated with it and for keeping track of all the sensor readings and switch posi- 
tions in its center. The LLP also executes scheduled changes in switch positions, sheds any loads which 
exceed their scheduled maximum, and switches redundant loads to their secondary bus if the load's 
primary source is interrupted. The LLP passes any or all of this information to the CUI software 1 10). 

The CUI software is resident in a Solbourne 5/501 UNIX-based work station. The CUI software 
routes information to the various LLP’s, controls LLP initialization, and serves as the man/machine 
interface for the entire system. Messages are passed from the three AI systems to the LLP's through the 
CUI via Ethernet communication links [10], Figure 7 shows the top-level main screen of the user 
interface. 

The FRAMES resides on the Solbourne 5/501 work station and is implemented in the common 
LISP object system (CLOS). This expert system watches over the entire EPS looking for anomalies and 
failures. FRAMES is responsible for detecting faults, advising the operator of appropriate corrective 
actions, and, in cases involving critical loads, autonomously implementing corrective actions through 
power system reconfigurations. FRAMES recognizes and adjusts to hard faults which the smart 
switchgear handles immediately, as well as handling soft faults, cascaded faults, and independent 
multiple faults [11], 

The LPLMS resides on the Solbourne 5/501 work station and is implemented in LISP. The 
LPLMS keeps track of the dynamic priorities of all payloads while developing and downloading current 
load shedding lists for the LLP’s every 15 min in preparation for contingencies which necessitate load 
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Figure 5. Representation for an ammeter. 
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Figure 7. The SSM/PMAD user interface (top level screen). 



shedding. This way, load shedding is implemented quickly in each load center or subsystem distributor. 
The LPLMS maintains a real-time dynamic representation of all the module loads and relevant facts so 
that applicable rules can fire to reorder portions of the load shedding list as situations change. The loads 
in a laboratory module may have dynamic properties. A critical noninterruptible materials processing 
experiment involving crystal growth will undoubtedly have a different priority as it nears completion. 
Other factors may change priorities such as equipment malfunctions. An expert system such as the 
LPLMS is crucial in determining which loads must be shed in the event ot perturbations to the available 
power. The LPLMS insures that critical loads not be shed unnecessarily [II]. 

MAESTRO resides on a Symbolics 3620D and is implemented in LISP. Special interfaces have 
been developed for MAESTRO which allow a great deal of flexibility in interactions with the scheduler. 
MAESTRO is a resource scheduler developed by Martin Marietta and can schedule and reschedule a 
number of payloads with various scheduling constraints. This AI system generates the baseline schedules 
for the EPS and accepts information from the other processors on when and how to reschedule module 
payloads. MAESTRO uses pieces of several AI technologies including object-oriented programming, 
heuristically guided search, activity library, expert functions, etc. MAESTRO schedules loads with 
regard to numerous resource constraints such as available crew members, supplies tor payloads, 
interdependence of payloads, power profiles, and thermal status [11]. 

In order to efficiently operate these three expert systems together, a simultaneous multiagent 
knowledge manager function called the knowledge management and design (KNOMAD) system was 
designed and built. KNOMAD utilizes a distributed data base management function to provide a 
modified blackboard management capability. The KNOMAD architecture is layered as shown in figure 
8. The central layer is the data base which provides a place for storing working memory data, for trans- 
ferring and sharing data, and for storing long-term data. The data base is modular and may be imple- 
mented as a distributed data base. As a distributed data base, multiple cooperating knowledge agents. 
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Figure 8. KNOMAD layered architecture. 
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each in different physical locations, could be supported. The next layer consists of an interface to the data 
base that provides a frame system for abstracting both data and procedure as well as a mechanism for 
storing simple facts. The top layer is the place where various tools are defined and implemented. All of 
the tools make use of the same data representation and thus easily share data across domains and func- 
tions [14]. FRAMES was implemented in KNOMAD in June of 1990 with LFLMS and a MAESTRO 
interface being implemented in April 1991. 


C. Operation 

The three Al systems interact such that when a hard fault occurs, the PMAD is immediately safed 
by smart switchgear in less than a microsecond. FRAMES recognizes the new configuration and decides 
if any other actions need to take place. FRAMES diagnoses the fault, recommends corrective action, 
and, where appropriate, autonomously implements the corrective action. If the system determines that 
the current loads schedule has been perturbated by the anomaly, MAESTRO is directed to reschedule the 
loads for the remainder of the crew period. The LPLMS then generates a new global load shedding list 
which is downloaded to the LLP’s. A similar sequence autonomously occurs in the event of a soft fault 
(except the switchgear does not trip) or when new directions or power allocation levels are sent to the 
EPS (through the operator interface). The operator may also take manual control of the system at any 
time [111. 

Before a planned system redesign (20 kHz, 208 Vac ring bus to a 120 Vdc star bus) was 
implemented, the system was exercised using a document called “SSM/PMAD Expository and Activity 
Plan” which contained a description of the tests required to demonstrate the operational capabilities of the 
SSM/PMAD software [15], The test bed was subjected to approximately 30 different test scenarios. 
These are described in detail in reference 10. The tests were quite successful in pointing out the strengths 
and weaknesses in the system software. 

After the initial system redesign was implemented, three of the test scenarios were repeated. 
These were a 1-kW hard fault, a 3-kW hard fault, and two 1-kW independent hard faults. Under the 
redesigned hardware and software, fault diagnosis speed increased from 5 min to 30 s for the first test, 
from over 10 min to about 1 min for the second test, and the last test which was not even possible with the 
old system took about I min to diagnose. 

Recent advances in the CUI, the LPLMS knowledge base, and the MAESTRO interfaces have 
produced additional increases in diagnosis speed and system capabilities. During one demonstration, a 
3-kW hard fault was injected into the system. The system responded by switching critical loads to their 
redundant buses in milliseconds, performing the correct fault diagnosis in tens of seconds, rescheduling 
two new loads, reprioritizing all of the remaining loads, and continuing normal operation. This entire 
process took less than 3 min. 


D. Future Projects 

At present, the SSM/PMAD breadboard is either fully autonomous or fully manual. This proves 
quite cumbersome especially during system troubleshooting or system parametric testing. Layers of 
intermediate autonomy will be developed so that the information contained in the system will be avail- 
able at any level desired by the user. 
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Finally, the SSM/PMAD breadboard is intended to support the development of the PMAD system 
for the space station modules with Boeing Aerospace Company on a noninterference basis and, to test 
intersystem communications, the SSM/PMAD breadboard has been interfaced with the Lewis Research 
Center APS demonstration program. In order to support both of these requirements, the SSM/PMAD will 
be interfaced with the AMPS hardware to provide a more realistic source for the SSM/PMAD. The block 
diagram for this system, called the LASEPS, is shown in figure 9 and is described in detail in 

reference 16. 
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Figure 9. Large autonomous spacecraft electrical power system (LASEPS). 


VII. CONCLUSIONS 


This paper has described the various activities at NASA/MSFC for advancing the state-of-the-art 
in spacecraft electrical power system automation. Based on the AMPS and SSM/PMAD projects, a 
hierarchical approach of distributed processing is being developed. In addition, AI and in particular, 
knowledge-based systems, are proving to be invaluable in accomplishing tasks not possible with conven- 
tional software. Thus, NASA/MSFC is progressing toward the eventual goal of a totally autonomous 
power system (with human override). 
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